Date: Tue, 13 Nov 2001 20:48:00 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Stefan Probst <stefan.probst@opticom.v-nam.net> Cc: Axel Scheepers <axel@axel.truedestiny.net>, John Baldwin <jhb@FreeBSD.org>, Rob Hurle <rob@coombs.anu.edu.au>, freebsd-security@FreeBSD.org Subject: Re: Adore worm Message-ID: <Pine.NEB.3.96L.1011113203251.56836B-100000@fledge.watson.org> In-Reply-To: <5.1.0.14.2.20011114005803.0207ed70@MailServer>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 14 Nov 2001, Stefan Probst wrote: > Thanks everybody for "encouraging" answers so far. > > I am in Vietnam, and the box is a dedicated server in the US :( > > There was nearly nothing installed, when I got it about two months ago, > and I installed several packages - all of them downloaded from the > original sites, in order to be sure to get the latest version. > > Will go to bed now and pray..... I still can telnet to the box. Maybe > somebody finds an idea what to do... Will see at my eMail tomorrow. Well, what you really need to do is reinstall from scratch, because once the machine has had a privileged account compromised, it will be effectively impossible to guarantee that no backdoors remain, and that you've successfully cleaned up. This is the big caveat, and common sense probably dictates it is the only reasonable choice. It's not a purely theoretical concern either :-). However, if you're willing to assume that the attacker limited their activities to those provided by the backdoor kit they used, then recovery is relatively straight-forward. Your first concern is to prevent additional access to the machine by both the current attackers, and anybody else who turns up. I don't know anything about the rootkit in question, but assuming its activities are limited to those described, you should be able to make use of ipfw to lock down the host such that only you source IP address can talk to it. You'll want to do this to prevent misuse of the host (i.e., as a stepping off point for additional attacks), and prevent additional intrusion. It may be you can ask your provider to provide this service at the router; you may also need to be careful about allowing appropriate DNS, or you may risk locking youself out. You then have two concerns: (1) disabling the kernel module and disabling effects of the kit, and (2) upgrading your system so that it is no longer vulnerable to whatever it was that let the attacker in in the first place. (1) probably consists of studying the kit to determine how it maintains its presence across reboots, and then disabling and rebooting, and then (2) requires you to remotely upgrade the operating system software. For relatively minor updates (4.2 -> 4.4), a remote upgrade is a feasible operation--ideally, you'll have access to a serial console so you can take care of the inevitable problem, but making use of the documented source upgrade procedures should be sufficient. Once you know the rootkit is disabled, mergemaster should also be an effective tool for helping you look for any changes to system configuration files. In particular, you'll want to look for changes to inetd.conf, password files, ssh configuration files, etc. Also, take this opportunity to check ~/.ssh/authorized_keys, ~/.ssh/.shosts for each user, .rhosts for each user, etc. Do not begin the upgrade until after you know the module and rootkit have been disabled, or they may interfere with the upgrade process. Finally, you'll need to do some more work to harden your hosts. As has been pointed out, you need to use encrypted services to access the host, rather than telnet. Especially in shared network environments, the risk of using unencrypted communications is very high. SSH can provide both remote login and file transfer services that are, in most cases, superior to the unencrypted alternatives, making it an easy switch for most :-). You'll want to clamp down on unnecessary services--recent versions of FreeBSD make this a lot easier by disabling most services by default. Finally, some words of warning: the procedure I've described above assumes that the hacker did only the bare minimum to leave the system in the state you've described it in. That they fairly mindlessly applied a remote exploit, and then fairly mindlessly applied a standard kit to the system. If they did anything more, then this procedure may not help. In fact, it could make it worse by giving you a false sense of assurance that things are fine :-). To recover properly, you must reinstall from trusted media, and using a trusted interface: in particular, when reinstalling, you must not boot from any writable media present in the system when or after the compromise occurred, and you must not rely on anything on the writable media during the recovery (in particular, binaries, but also many other things). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1011113203251.56836B-100000>